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1  Introduction 


Background 

River  flooding  is  one  of  the  disasters  that  Army  land  managers  and  emergency 
planners  must  address.  During  emergency  flood  conditions,  the  National  Weather 
Service  (NWS)  provides  flood  forecasts  and  warning  services,  while  the  Federal 
Emergency  Management  Agency  (FEMA)  directs  flood  response  activities.  The  U.S. 
Army  Corps  of  Engineers  (USACE)  may  assist  these  agencies,  particularly  where 
Corps’  reservoirs  and  other  projects  influence  flood  conditions.  By  regulating  the 
discharges  from  its  reservoirs,  the  Corps  may  help  to  minimize  flooding  downstream 
or  to  delay  flooding  until  downstream  areas  are  evacuated  or  other  necessary  actions 
are  taken  (Fischenich  1992).  Rapid  generation  and  assessment  of  information  on 
downstream  flood  extent  based  on  predicted  climatic  conditions  and  reservoir 
discharge  schedules  would  enhance  the  Corps’  contribution  to  real-time  flood  response. 
Already  available  computer  packages  make  it  possible  to  track  storms,  predict  storm 
paths,  simulate  overland  and  channel  flows,  estimate  river  depths,  and  overlay  flood 
extents  on  digital  data  bases  containing  human  and  economic  information.  Graphical 
user  interfaces  (GUIs)  and  geographic  information  system  (GIS)  tools  can  be  developed 
to  help  Corps’  district  and  division  offices  generate  this  information  by  seamlessly 
linking  underlying  computer  models  into  a  decision  support  system  (DSS). 

Implementation  of  hydrologic  models  and  geographic  information  systems  within  a 
decision  support  system  can  allow  planners  with  limited  expertise  in  hydrology  to 
rapidly  generate  and  assess  information  related  to  flood  conditions  and  control 
strategies.  While  current  literature  establishes  the  use  of  GISs  within  floodplain 
management  studies  for  estimation  of  floodplain  extent  and  expected  long-term 
economic  and  other  impacts  from  flooding,  the  use  of  GISs  within  emergency  response 
systems  is  not  yet  a  well-documented  practice  (Cotter  1989;  Depodesta  et  al.  1991; 
Purves  et  al.  1991;  Thompson  et  al.  1991). 

Several  factors  have  limited  the  real-time  systematic  use  of  modeling  and  GIS 
capabilities  for  flood  prediction  and  assessment.  One  factor  is  that  real-time  flood 
prediction  and  assessment  requires  multiple  components,  including  precipitation 
forecasting  and  monitoring,  hydrologic  and  hydraulic  modeling,  spatial  analysis  and 
query,  and  graphical  display.  The  varying  data  and  procedural  requirements  of  these 
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components  usually  demand  time-consuming  data  translation  and  editing.  Another 
factor  limiting  real-time  use  is  that  multiple  stages  of  analysis  are  required  for  flood 
prediction  and  assessment,  including  the  selection  of  models,  the  selection  of  data 
sources,  and  the  interpretation  of  results.  Because  emergency  response  is  infrequently 
practiced,  questions  regarding  the  proper  sequence  of  tasks  are  likely  to  arise  and 
hinder  progress  toward  the  creation  of  information  useful  for  decisionmaking. 
Furthermore,  the  typical  output  of  hydrologic  and  hydraulic  modeling  components  are 
peak  discharges  at  point  locations,  and  water  surface  elevations  at  specified  channel 
cross-sections.  This  output  may  not  be  immediately  useful  to  the  decisionmaker 
attempting  to  assess  downstream  impacts  from  flooding:  such  analyses  require 
anticipated  depth-over-time  information.  Manual  interpolation  of  modeling  results 
into  more  informative  maps,  graphs,  and  charts  is  time  consuming  and  does  not 
support  real-time  flood  assessment. 


Objective 

The  objective  of  this  report  is  to  describe  the  development  of  a  graphical  user  interface 
(GUI)  for  an  emergency  flood  prediction  and  assessment  system.  This  system  provides 
procedural  support  and  improved  information  transfer  to  the  user. 


Approach 

The  Readiness  Management  System  (RMS),  conceived  and  developed  by  Omaha 
District  U.S.  Army  Corps  of  Engineer  staff,  was  chosen  as  the  basis  for  the  develop¬ 
ment  of  a  prototype  GUI  (Omaha  District  COE).  The  purpose  of  RMS  is  to  improve 
flood  response  time  through  accelerated  generation,  retrieval,  and  assessment  of  flood 
data  (Fischenich  1991).  As  such,  RMS  provided  a  good  basis  for  demonstrating  the 
potential  for  creating  GUIs  that  unify  existing  computer  technologies  into  tools  or 
systems  for  emergency  decisionmaking.  GUI  and  GIS  capabilities  support  accelerated 
retrieval  and  assessment  of  data.  An  analysis  of  RMS  was  conducted  to  characterize 
the  potential  user,  system  tasks,  user  perceptions  and  terminology,  and  desired 
software  components.  A  prototype  GUI  was  subsequently  developed  and  demonstrated 
at  Omaha  during  the  Oahe  Dam  Safety  Exercise  in  September  1992.  The  prototype 
was  evaluated  based  on  interface  standards  established  in  current  literature  on 
interface  design.  Potential  users  of  the  GUI  provided  a  general  evaluation  of  the 
system,  which  is  also  documented  in  this  report. 
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Scope 

The  GUI  prototype  was  specifically  designed  to  integrate  the  components  of  RMS 
selected  by  Omaha  district  to  model  flooding  and  impacts  on  the  Missouri  River  from 
the  Oahe  Dam,  Pierre,  SD,  downstream  to  Big  Bend  Dam  at  Fort  Thompson,  SD. 
Several  of  the  system  components  chosen  by  Omaha  District  are  well  accepted  tools, 
such  as  the  river  modeling  software  developed  by  the  Hydrologic  Engineering  Center 
(HEC)  (Feldman  1992).  Other  components  constitute  relatively  new  and  as-yet 
unproven  technology.  This  report  does  not  attempt  to  evaluate  the  accuracy  of  the 
modeling  components,  but  rather  to  demonstrate  how  modular  GUI  programs  can 
permit  the  integration  of  independently  developed  software  systems  into  a  single 
system  for  use  in  rapid  flood  prediction  and  assessment.  The  interface  does  not  alter 
the  functioning  of  any  individual  software  component,  but  rather  links  the  data  flows 
between  components  and  provides  a  cohesive  environment  for  system  use. 

This  interface  is  not  intended  to  completely  eliminate  the  need  for  hydrologic  and 
hydraulic  modeling  expertise  during  flood  simulation.  Data  translation  and  editing 
not  requiring  expert  judgment  is  computer  automated,  but  some  model  input  tasks 
require  hydrologic  or  hydraulic  expertise  to  correctly  reflect  real-time  conditions. 


Mode  of  Technology  Transfer 

The  research  documented  writhin  this  report  will  contribute  to  continued  research  and 
development  of  a  GUI  for  flood  prediction  and  response,  to  be  conducted  at  the  U.S. 
Army  Corps  of  Engineers  Cold  Regions  Research  and  Engineering  Laboratory 
(CRREL). 
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2  Approaches  to  Emergency  Flood  Prediction 
and  Assessment 

Computer-Based  Systems 

Computer-based  systems  have  been  developed  for  real-time  flood  forecasting.  These 
systems  are  based  on  the  control  of  a  number  of  techniques  using  interactive  software. 
Common  capabilities  integrated  within  these  systems  include  data  acquisition  and 
processing,  precipitation  analysis,  streamflow  forecasting,  reservoir  system  analysis, 
and  graphical  display  of  data  and  simulation  results  (Unver,  Mays,  and  Lansey  1987, 
pp  620-638). 

Feldman  (1992)  provides  an  overview  of  the  numerous  modeling  tools  developed  at  the 
Hydrologic  Engineering  Center  (HEC)  for  water  control  applications.  The  existing 
suite  of  HEC  models  includes  the  HEC-1F  model,  which  can  be  used  for  computing 
expected  annual  economic  damage  for  different  flood  control  alternatives  based  on 
historic  or  forecast  data  (USACE  1989).  The  HEC-5  model  for  the  simulation  of  flood 
control  and  conservation  systems  operates  reservoirs  to  minimize  flooding  at  specified 
control  points  within  the  channel,  although  it  does  not  indicate  expected  flooding  in 
areas  beyond  the  channel  (Feldman  1992,  p  250).  The  HEC-2  model  generates  water 
surface  elevations  at  defined  channel  cross-sections.  Computer-based  systems  have 
been  created  specifically  for  real-time  flood  assessment.  Tennessee  Valley  Authority 
(TVA)  software  systems  have  been  developed  to  provide  rapid  evaluation  of  a  large 
number  of  (reservoir)  operation  alternatives  and  an  improved  information  base  for 
decisionmaking  (Brown  and  Shelton  1986,  pp  409-418).  Suggested  applications 
include  the  estimation  of  flood  profiles,  although  not  of  flooded  area.  A  decision- 
support  computer  model,  BRASS  (basin  runoff  and  streamflow  simulation),  was 
developed  by  Savannah  District  COE  to  improve  real-time  prediction  of  flood  dis¬ 
charges  and  stages,  and  to  aid  in  flood  management  decisions  within  the  Savannah 
River  System  (Colon  and  McMahon  1987,  p  177).  BRASS  is  used  to  generate 
information  such  as  critical  flood  stages,  discharges,  and  maxmin  data  in  tabular 
output  and  printer  plot  format  (McMahon  1989,  pp  125-127). 

A  computer-based  flood  prediction  sequence  is  described  by  Hoggan  et  al.  (1991,  pp 
1061-1066).  The  sequence  begins  with  the  calculation  of  stream  flow,  including  the 
contribution  from  tributary  inflows.  Stream  flow  data  are  collected  from  automated 
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stations,  and  headwater  and  tailwater  elevations  from  dams  located  within  the 
modeled  reach.  Flow  rates  are  determined  from  stage  values  for  selected  sites  using 
stage/discharge  functions  encoded  within  the  computer  system.  For  ungaged  drainage 
areas,  rainfall  data  is  collected  from  recording  stations  and  flow  rates  determined  by 
hydrologic  models.  Flood  routing  models  are  used  to  calculate  water  surface  profiles 
at  specific  points  within  the  described  channel.  A  geometric  model  is  required  to 
describe  cross  sections  and  reach  lengths.  Depending  on  the  hydraulic  model  chosen, 
required  input  data  may  include  computed  or  gaged  stream  discharge,  flow  regime, 
starting  water  surface  elevation,  and  channel  roughness.  The  final  output  of  the  flood 
prediction  system  may  include  computed  discharge  and  stage  hydrographs  at  major 
inflow  points  and  other  prespecified  locations  within  the  systems  as  well  as  water 
surface  elevations  at  cross-section  locations. 

This  system  output  may  be  used  to  warn  emergency  management  centers  of 
dangerously  high  discharges  or  stages.  It  does  not,  however,  give  an  explicit  indication 
of  the  relationship  between  reservoir  release  and  downstream  impacts,  and  is  thus  of 
limited  use  to  help  decide  reservoir  release.  The  output  becomes  more  useful  to  the 
decisionmaker  when  it  is  translated  into  maps  of  flood  extent  and  degree  that  can  be 
used  to  predict  impact  on  the  population  and  likely  land  use  and  site  damage.  Manual 
interpolation  of  modeled  water  surface  elevations  into  such  maps  is  very  time- 
consuming  however,  and  usually  requires  a  good  understanding  of  the  terrain  of  the 
modeled  area.  The  subsequent  overlay  of  site,  infrastructure,  and  land  area  maps  to 
gain  the  flood  impact  information  is  also  a  very  time-consuming  task  when  done 
manually. 


Spatial  Analysis  With  Geographic  Information  Systems  (GIS) 

The  incorporation  of  the  spatial  analysis  capabilities  of  a  GIS  into  flood  response 
systems  can  increase  the  effectiveness  of  such  systems.  In  addition  to  increasing  the 
speed  and  scale  of  data  manipulation,  GIS  can  also  enhance  the  interpretation  of 
typical  hydrologic  and  hydraulic  model  output.  A  GIS  may  be  used  to  automate  the 
interpolation  of  channel  water  surface  elevations  into  water  surface  elevation  maps, 
to  overlay  water  surface  maps  onto  topographic  maps  to  determine  flood  depth,  and 
to  identify  sites  lying  within  the  flooded  area. 

Both  hydrologic  and  hydraulic  models  may  be  linked  to  GIS  to  support  flood  prediction. 
While  the  use  of  GIS  in  conjunction  with  hydrologic  and  hydraulic  models  is  not  a  new 
concept  (Shea  et  al.  1993,  p  112),  it  has  become  more  widespread  and  sophisticated  in 
relation  to  water  resources  applications  with  the  increase  in  the  availability  and 
sophistication  of  GIS.  Kurt  Fedra  (1991)  identifies  two  general  levels  of  hydrologic 
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model  linkage  with  a  GIS.  In  the  first  level  of  linkage,  models  merely  read  input  from 
GIS  files  and  produce  output  that  can  be  displayed  with  the  GIS.  This  usually  involves 
little  software  modification  and  only  requires  adaptation  of  file  formats  and  of  input 
and  output  routines.  The  next  level  of  linkage  identified  involves  the  sharing  of  files 
among  several  separate  hydrological  analysis  components  through  the  creation  of  a 
common  interface. 

The  potential  for  using  GIS  in  real-time  flood  control  systems  has  been  recognized  by 
various  government  agencies  and  offices.  At  the  time  of  literature  review,  a  flood 
control  system  that  includes  the  use  of  GIS  had  been  described  but  not  yet  imple¬ 
mented  by  county  personnel  of  Jefferson  Parish,  LA  (Thompson  1991,  p  149).  This 
flood  control  system  is  proposed  for  reservoir  control  in  periods  of  potential  flooding, 
as  well  as  for  emergency  preparedness  and  remedial  action.  The  stated  goal  of  this 
project  is  to  provide  “easy  access  to  highly  accurate  spatial  information”  that  can  also 
be  graphically  displayed.  Note  that  the  accuracy  of  information  produced  by  an 
emergency  response  system  depends  on  the  quality  of  the  data  input  in  addition  to  the 
modeling  and  data  manipulation  techniques  themselves.  Studies  that  test  the 
accuracy  of  GIS-techniques  and  GIS-produced  information  remain  scarce. 

The  U.S.  Army  Engineer  District,  New  Orleans  used  GIS  techniques  to  study  flood 
protection  alternatives  as  they  relate  to  hydrologic,  environmental,  and  socio-economic 
impacts  to  a  study  area  (Ratcliff  and  Cunningham  1991,  pp  87-89).  While  this  project 
is  innovative  in  its  use  of  GIS  and  satellite  imagery  for  floodplain  management,  it  does 
not  require  real-time  information  and  thus  not  the  same  degree  of  integration  as  a  true 
emergency  response  system.  Depodesta  et  al.  (1991)  outline  the  development  of  an 
interface  between  HEC-2  and  GIS  for  floodplain  management,  which  they  suggest  will 
eventually  include  real-time  flood  forecasting.  The  Regional  Flood  Control  District  of 
Clark  County,  NY  is  implementing  GIS  to  support  planning  and  engineering  functions 
(Purves  1991,  p  328).  They  have  assessed  the  requirements  of  using  GIS  to  support 
flood  control  planning,  and  imply  that  the  operation  of  an  Advanced  Flood  Warning 
System  using  GIS  is  desired. 

The  Fort  Worth  District  of  USACE  has  extensively  investigated  and  evaluated 
methods  by  which  GIS  can  be  integrated  into  water  and  land  resource  planning 
(USACE  Fort  Worth  District  1991).  Among  their  specific  study  objectives  was  the 
automation  of  computer  links  between  GIS  and  the  HEC-1  hydrologic  model  and  the 
HEC-2  hydraulic  model  for  assessing  the  benefits  of  a  flood  control  project.  Although 
their  study  was  not  geared  toward  real-time  flood  prediction  and  assessment,  the 
automated  flood  damage  analysis  methods  they  developed  are  of  potential  benefit  to 
real-time  flood  prediction  systems. 
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The  Federal  Emergency  Management  Agency  (FEMA)  has  also  considered  coupling  the 
HEC-1  and  HEC-2  modeling  programs  with  GIS.  Daniel  Cotter,  of  the  Federal 
Insurance  Administration  of  FEMA,  has  stated  that  the  goal  is  to  link  automated  data 
collection  techniques  and  GIS  technology  with  computer-based  flood  simulation 
packages  to  provide  an  efficient,  automated  process  for  developing  FIS  (Flood 
Insurance  Studies)  and  FIRMs  (Flood  Insurance  Rate  Maps)  (Cotter  1989,  p  85). 
While  the  creation  of  flood  hazard  maps  does  not  require  real-time  data  processing, 
this  type  of  automated  technology  may  potentially  be  applied  to  FEMA  s  and  other 
agencies’  emergency  management  systems.  It  has  indeed  been  stated  that  the 
Integrated  Emergency  Management  Information  System  (IEMIS)  being  developed  by 
FEMA  is  intended  to  combine  GIS  capabilities  with  analytical  models  for  the  analysis 
of  natural  and  technological  hazards  and  to  provide  an  interactive  computer  system 
for  emergency  managers. 

Despite  the  fact  that  rapid  spatial  assessment  of  floods  has  been  identified  as  valuable 
for  effective  flood  response,  documented  flood  response  systems  still  mainly  provide 
point  channel  discharges  or  water  surface  elevations  to  emergency  personnel.  The 
comprehensive  linkage  of  GIS  to  such  systems  is  still  in  the  developmental  stage.  It 
has  been  suggested  that  rather  than  investing  solely  in  solutions  that  shorten  response 
time  or  waiting  for  technological  solutions  that  increase  forecast  lead  time,  that  a  more 
cost-effective  alternative  would  be  to  develop  analytic  models  that  help  decisionmakers 
better  use  forecast  information  (Krzysztofowicz  and  Davis  1984,  p  11).  The  develop¬ 
ment  of  advanced  user  interfaces  that  provide  decision  support  and  procedural  support 
as  well  as  a  link  to  GIS  and  computerized  models  are  needed  to  help  the  decisionmaker 
make  the  optimal  emergency  response. 


System  Integration  Using  Graphical  User  Interfaces  (GUI) 

To  address  the  use  of  multiple  models  and  users  with  varied  computing  and  technical 
abilities,  a  user  interface  shell  linking  the  models  within  a  unified  user  environment 
may  be  developed.  A  GUI  can  permit  the  use  of  multiple  software  components  needed 
for  a  system  task  while  leaving  the  user  free  to  concentrate  on  the  task  rather  than  on 
operations  of  the  system  design  (Brown  1988,  p  4).  Implementing  a  graphical  user 
interface  (GUI)  is  a  particularly  effective  way  to  improve  user  understanding  of  a  task 
(Powell  1990). 

In  an  article  on  modeling  and  computer  simulation  in  disaster  response,  McCoy  (1983, 
p  43)  states  that  “the  ultimate  goal  of  the  computer  simulation  for  emergencies  is  to 
enable  emergency  managers  to  maximize  the  use  of  information  and  resources  so  as 
to  reduce  the  impact  of  a  disaster  on  their  communities.”  Successful  transfer  of 
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information  between  the  computer  system  and  the  user  is  critical  in  meeting  this  goal. 
A  GUI  can  improve  information  transfer  between  the  computer  system  and  the  user 
by  making  the  system  and  its  components  less  confusing  to  use,  providing  procedural 
guidance  that  reduces  the  time  of  system  operation,  and  by  providing  information  in 
a  variety  of  forms,  such  as  text,  graphs,  and  maps. 

Frysinger  (1993)  states  that  the  goal  of  environmental  decision  support  systems 
(EDSS)  that  use  multiple  technologies  to  assist  complex  management  decisions  is  “to 
make  information  available  to  humans  in  a  form  which  maximizes  the  effectiveness 
of  their  cognitive  decision  process.”  A  GUI  can  help  the  translation  of  conventional 
model  output  into  information  known  to  be  directly  useful  for  decisionmaking.  It  can 
facilitate  the  quick  input  and  retrieval  of  relevant  information  and  prevent  distraction 
from  unnecessary  information.  Thimbleby  (1993)  points  out  that  not  only  does  an 
interface  augment  a  system  (increases  its  speed,  quality,  and  complexity  of  analysis), 
but  it  can  also  empower  the  user  to  perform  new  forms  of  analysis  based  on  the 
additional  information  generated. 

In  addition  to  benefiting  the  end  user,  the  development  of  a  GUI  that  links  existing 
computer  technology  may  improve  efficiency  during  the  system  development  stage. 
Djokic  (1993)  makes  a  case  for  creating  interfaces  that  unify  existing  GIS,  expert 
system,  numerical  modeling,  and  utility  software  into  systems  for  support  of  complex 
decisions  based  on  some  kind  of  spatially  distributed  system.  These  justifications  for 
the  development  of  interfaces  include  the  fact  that  energy  does  not  have  to  be  spent 
customizing  existing  code  or  writing  new  code  for  each  specific  task.  The  system 
developer  may  concentrate  on  developing  the  system  application  rather  than  the 
computer  environment. 
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3  Methodology 

Interface  Analysis 

The  success  of  a  user  interface  in  providing  procedural  support  and  improving 
information  transfer,  depends  on  thoughtful  interface  analysis  and  design.  Current 
literature  documents  the  general  steps  for  successful  interface  analysis  and  design. 
The  following  paragraphs  are  based  on  Sutcliffe’s  (1988)  description  of  the  essential 
steps:  analysis  of  user  characteristics,  task  analysis,  recording  of  user  perceptions  and 
terminology,  and  synthesis  of  this  information  within  the  constraints  of  hardware  and 
software. 

The  objective  of  user  analysis  is  to  obtain  knowledge  of  the  skills  and  experience  of 
potential  users  to  predict  what  type  of  interface  design  they  will  find  useful  and  easy 
to  operate.  Users  with  little  experience  with  system  components  or  with  computers 
in  general  or  who  will  have  frequent  or  long  gaps  in  interface  use,  will  require 
additional  help  facilities  and  prompting  and  a  more  explicit  interface  presentation. 

Task  analysis  is  used  to  discover  the  required  functions  and  operational  sequence  of 
a  system.  Identification  of  the  desired  system  output  is  also  an  essential  part  of  task 
analysis.  Tasks  are  divided  into  those  done  by  the  computer,  which  include  repetitive 
tasks  such  as  calculations  and  data  handling,  those  done  by  the  user,  such  as 
judgments  and  heuristic  reasoning,  and  those  shared  by  the  computer  and  the  user, 
such  as  data  entry,  data  retrieval,  and  decision  support.  (Those  tasks  shared  by  the 
computer  and  user  will  be  explicitly  represented  in  the  interface.)  Computer  tasks  do 
not  need  to  be  apparent  to  the  user. 

Recording  tasks  in  terms  of  user  perceptions  and  terminology  is  critical  for  the  creation 
of  an  interface  that  provides  effective  procedural  support.  The  names  people  use  for 
objects  and  functions  in  the  system,  the  connections  made  between  tasks,  and  the 
visual  and  verbal  metaphors  used  to  describe  tasks  may  be  incorporated  into  the 
designer’s  conceptual  model  of  the  system  (Sutcliff  1988).  Literature  on  the 
development  of  user  interfaces  often  describes  “the  user  model”  as  the  user  s  mental 
model  of  a  system.  The  designer’s  idea  of  what  this  mental  model  is  becomes  the 
conceptual  model  for  the  interface  design. 
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Sutcliff  describes  several  types  of  user  models,  including  theoretical  cognitive  models: 
(1)  models  of  user  knowledge,  constructed  to  understand  how  users  learn  and  which 
describe  users  knowledge  in  terms  of  plans  and  procedures,  (2)  models  of  user 
characteristics,  which  classify  users  in  terms  of  skills  and  ability,  (3)  user  task  models, 
which  reflect  how  much  users  know  about  the  system  in  terms  of  its  operation  and 
expectations  of  how  it  will  work,  and  finally,  (3)  user  views,  which  present  system 
components  in  terms  of  visual  metaphors  or  verbal  classification  of  meaning  to  the 
potential  users.  The  more  an  interface  conforms  to  users’  preconceived  notions  of  how 
it  should  appear  and  operate,  assuming  that  these  notions  are  accurate,  the  easier  it 
will  be  to  learn  and  less  stressful  to  use.  Task  models  and  user  views,  in  addition  to 
user  characteristics,  are  described  as  being  of  the  most  direct  relevance  to  standard 
interface  design  and  have  been  used  as  the  conceptual  basis  of  interface  design  for  this 
project.  The  availability  and  capabilities  of  software  and  hardware  will  determine 
what  type  of  interface  can  be  designed  to  meet  user  needs  and  support  the  required 
tasks. 


Interface  Standards 

Measures  of  good  interface  design  are  commonly  cited  in  literature  on  computer 
interfaces.  Brown  (1988,  p  21)  defines  general  concepts  for  human-computer  interface 
development  that  may  be  used  as  standards  for  interface  design.  These  include  the 
minimization  of  mental  processing  requirements,  the  efficient  allocation  of  functions 
between  the  user  and  computer,  the  support  of  a  user’s  mental  model  for  the  system, 
and  making  the  interface  easy  to  learn,  easy  to  use,  and  functional.  It  is  also 
important  that  a  GUI,  particularly  one  developed  for  decision  support,  improve 
information  transfer  between  the  user  and  the  computer  by  directly  reflecting  the 
decisionmaking  process  in  its  procedural  structure  and  by  providing  direct  and  reliable 
access  to  the  information  essential  for  decisionmaking.  Superfluous  distracting 
information  is  eliminated,  and  needed  information  displayed  in  an  easily  interpreted 
format.  While  it  is  important  to  consider  how  visual  information  can  be  displayed  to 
optimize  its  use  to  the  observer,  discussion  of  the  theory  of  human  cognition  as  it 
relates  to  computer  graphics  is  beyond  the  defined  scope  of  this  study.  The  following 
paragraphs  discuss  standards  of  interface  design  in  more  detail,  based  on  the 
definitions  by  Brown. 

Brown  (1988,  pp  6-7)  suggests  that,  for  an  interface  to  be  a  useful  tool,  it  must  reduce 
the  number  of  mental  processing  operations  required  for  its  use.  Mental  processing 
operations  are  defined  as  requirements  for  the  user  to  learn  complex  commands  and 
syntax,  memorize  encrypted  code  or  formats,  and  translate  data  into  units  or  formats 
before  they  can  be  applied  to  the  problem. 
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The  number  of  menial  tasks  done  by  the  user  should  be  reduced.  Functions  best  done 
by  the  computer  include  the  storage  and  recall  of  large  amounts  of  data  and  the 
processing  of  data  using  prespecified  procedures,  while  functions  best  done  by  humans 
include  monitoring,  serving  as  decisionmaker,  and  responding  to  unexpected  events. 
The  user  should  not  have  to  commit  commands  necessary  to  perform  a  task  to  memory, 
but  rather  should  be  able  to  choose  from  a  list  of  options. 

The  development  of  an  accurate  mental  model  of  the  system  may  be  promoted  by 
designing  the  static  structure  of  the  interface  to  reflect  the  procedural  sequence  of 
activity,  and  using  descriptive  labels  to  identify  operations  within  the  system  (Powell 
1990,  pp  35-72).  Consistent  interactions  between  the  user  and  the  system  are 
necessary  if  the  user  is  to  build  an  understanding  of  system  operation  (Scheinderman 
1987).  Brown  states  that  a  measure  of  the  ease  of  learning  is  the  extent  to  which  a 
user  may  become  proficient  with  minimal  training  and  that  a  measure  of  ease  of  use 
is  the  extent  to  which  tasks  may  be  performed  with  minimal  effort. 
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4  System  Development 

The  Application 

The  Readiness  Management  System  (RMS)  under  development  by  the  Omaha  District 
of  the  Corps  of  Engineers  is  intended  to  improve  the  response  time  to  flood  emergen¬ 
cies  through  accelerated  generation,  retrieval,  graphic  representation,  and  assessment 
of  flood  data.  Important  to  the  implementation  of  this  system  is  the  development  of 
an  interface  linking  the  various  modeling  and  GIS  components  required  for  flood 
prediction  and  providing  procedural  support  to  the  users.  By  clearly  directing  the 
sequence  of  system  execution,  the  interface  may  guide  planning  staff  through  the  steps 
of  emergency  flood  simulation,  and  by  linking  the  system  to  the  spatial  analysis  and 
graphic  presentation  capabilities  of  a  GIS,  provide  flood  prediction  results  in  a  format 
that  aids  rapid  impact  assessment  and  subsequently  decisionmaking. 

The  RMS  prototype  was  developed  for  the  portion  of  the  Missouri  River  stretching 
from  the  Oahe  Dam  at  Pierre,  SD  to  Big  Bend  Dam  at  Fort  Thompson,  SD.  Impact 
assessment  activity  concentrates  on  Pierre  and  the  nearby  rural  regions. 

The  methodology  outlined  in  Chapter  3  will  be  used  as  the  framework  for  discussion 
of  interface  development.  User  characteristics  are  first  described,  followed  by  task 
analysis,  user  perceptions,  and  system  requirements.  The  information  gained  through 
interface  analysis  was  used  as  the  basis  for  interface  development,  the  results  of  which 
are  described  in  the  proceeding  chapter.  Information  was  obtained  through  interviews 
with  members  of  the  RMS  development  staff. 


User  Analysis 

The  goal  of  user  analysis  is  to  identify  the  potential  users  of  RMS,  their  likely 
expertise,  the  probable  length  and  frequency  of  training,  and  the  frequency  of  use  of 
the  system.  Rather  than  being  developed  for  analysts,  the  system  is  intended  to  help 
decisionmakers  coordinate  the  flood  prediction  and  analysis  tasks  of  staff  members. 
The  ultimate  users  were  Corps  of  Engineers  district  and  division  decisionmakers  with 
varying  levels  of  training  in  the  system  components.  Familiarity  with  GIS  and 
computers  in  general  may  vary  widely  as  well. 
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Training  on  the  system  cannot  alone  ensure  a  system  that  the  users  understand. 
There  are  often  gaps  of  months  or  years  in  the  use  of  an  emergency  readiness  system. 
Without  continual  use,  users  may  forget  their  system  training.  In  addition,  providing 
extensive  training  to  the  current  staff  is  of  questionable  value  because  of  the 
uncertainty  about  who  will  actually  be  available  to  operate  the  system  during  an 
emergency.  It  was  concluded  that  the  system  should  be  operable  by  a  user  with 
minimal  training  on  the  system.  The  interface  should  be  highly  “user  friendly”  (i.e., 
one  that  carefully  directs  the  user  through  the  prediction  and  assessment  process). 
The  interface  is  not  intended  to  replace  the  need  for  hydrologic  or  hydraulic  modeling 
expertise.  Those  models  that  require  real-time  calibration  must  still  be  managed  by 
those  with  hydrologic  expertise.  The  GUI  provides  the  decisionmaker  an  opportunity 
to  coordinate  staff  activities  for  real-time  production  of  information  useful  for 
decisionmaking. 


Task  Analysis 

Task  analysis  as  described  in  Chapter  3  was  undertaken  to  determine  system 
functions,  operational  sequence,  software  components,  and  data  requirements.  It  was 
also  important  to  analyze  the  decision  process  itself  to  characterize  the  interface  in 
terms  of  the  information  needs  of  the  decisionmaker.  Task  analysis  was  originally 
conducted  by  phone  interview  with  one  of  the  Omaha  District  decisionmakers.  In 
follow-up  to  this  conversation,  a  chart  showing  basic  modeling  components,  data 
inputs,  and  data  outputs  was  provided.  Through  analysis  of  this  chart,  tasks  were 
allocated  to  either  the  user,  the  computer,  the  user  and  the  computer,  or  the  technician 
working  “outside”  the  interface.  Data  were  identified  as  either  that  to  be  input  by  the 
user  through  the  interface  or  that  which  could  be  accessed  by  the  computer  “behind  the 
scenes.”  Real-time  data  were  categorized  as  those  that  could  be  input  by  the  user 
based  on  readily  available  information,  such  as  gage  reports  or  desired  reservoir 
operation  scenarios,  and  those  that  required  preparation  by  specialists  familiar  with 
individual  models.  This  information  was  important  in  deciding  how  the  flood 
prediction  and  assessment  process  could  be  automated  and  directed  by  the  interface 
to  make  efficient  use  of  the  time  of  staff  technicians  and  decisionmakers  alike.  While 
data  needs  were  not  specifically  outlined  in  the  RMS  function  chart,  the  “GIS  User 
Information  Requirements”  developed  by  the  Headquarters  U.S.  Army  Corps  of 
Engineers  (HQUSACE)  Study  Group  for  Emergency  Management  Use  of  EIS/GIS 
(EMIS-SDTG)  (1992)  were  chosen  by  Omaha  to  be  a  basis  for  determining  information 
needs. 

Three  main  RMS  tasks  were  identified:  flood  prediction,  flood  assessment  (both  in 
Figure  1),  and  graphical  display.  Flood  prediction  has  the  most  defined  sequence  of 
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Figure  1 .  RMS  functional  flow  chart. 


operation.  It  must  precede  flood  assessment  unless  the  results  of  a  previous 
simulation  are  being  used.  The  sequence  begins  with  the  calculation  of  precipitation 
values  by  the  U.S.  Army  Waterways  Experiment  Station  (USAWES)  rainfall  prediction 
software,  using  National  Weather  Service  ground-based  radar  data  input  (Fischenich 
1991)  (Figure  1,  upper  left).  The  predicted  precipitation  values  are  stored  in 
Hydrologic  Engineering  Center’s  (HEC’s)  Data  Storage  System  (DSS)  format  for 
subsequent  use  by  the  HEC-1F  stream  flow  forecasting  program  (represented  in 
Figure  1  at  “Hydrologic  Model”).  The  HEC-1F  program  is  used  in  two  stages,  one  for 
parameter  estimation  and  one  for  precipitation-runoff  simulation.  Parameter 
estimation  is  performed  first  using  an  “emodel”  input  file.  During  this  stage,  the 
program  accesses  the  predicted  precipitation  values  previously  stored  in  DSS  format. 
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Output  is  also  stored  within  a  DSS  file.  Two  hydrographs,  two  loss  rates,  and  two  base 
flow  parameters  must  be  encoded  in  the  emodel  file  at  the  time  of  forecast.  An  existing 
text  input  file  for  HEC-1F,  based  on  previous  model  calibration,  may  be  directly  edited 
by  the  hydrologist  to  include  these  parameters  or  by  using  the  HEC-1F  preprocessor 
program,  PREFOR,  which  fills  in  selected  input.  Real-time  application  of  the 
calibrated  model  is  required  to  allow  additional  modification  and  fine  tuning  of 
parameters  for  real-time  modeling  (USACE  1989,  p  23).  HEC-1F  is  then  run  with  the 
fmodel  input  file.  The  subbasin  hydrographs  generated  from  the  emodel  stage  as  well 
as  observed  hydrographs  are  accessed  from  DSS  files.  A  peak  discharge  value  for  the 
outlet  of  the  Bad  River  tributary  is  extracted  from  HEC-1F  fmodel  output  for 
subsequent  addition  to  the  discharge  values  used  in  the  HEC-2  input  file.  It  is 
assumed  that  the  peak  discharge  for  the  tributary  occurs  at  the  same  time  as  the  peak 
for  the  Missouri.  This  may  be  unlikely,  and  represents  a  worst-case  scenario. 

The  HEC-2  Water  Surface  Profiles  program  (“Hydraulic  Model”  in  Figure  1)  is  used  to 
generate  water  surface  elevations  at  channel  cross-sections  (USACE  1990b). 
Upstream  and  downstream  boundary  conditions  and  reservoir  releases  can  be  input 
into  a  pre-existing  HEC-2  input  file.  This  input  file  is  also  used  to  describe  channel 
geometry  and  reach  length.  The  downstream  pool  stage  is  input  as  the  starting  water 
surface  elevation.  Upstream  boundary  conditions  are  input  as  a  spillway  discharge 
value  at  the  cross-section  corresponding  to  the  spillway  location.  Reservoir  release  is 
input  as  a  discharge  value  at  the  final  upstream  cross-section  location.  The  HEC-2 
output  files  may  provide,  among  other  information,  water  surface  elevations  for 
channel  cross-sections  defined  in  the  HEC-2  input  file.  A  GRASS  f-tools  program, 
f.input,  extracts  water  surface  elevations  from  the  HEC-2  output  file  for  every  cross- 
section  that  corresponds  to  the  required  vector  cross-section  map  (Betancourt  1992). 
Another  GRASS  program,  f.wsurf,  interpolates  these  elevation  values  into  a  water 
surface  map,  which  it  then  overlays  with  a  digital  elevation  model  (DEM)  to  create  a 
flood  depth  map.  The  actions  provided  by  the  f-tools  programs  are  shown  in  Figure  1, 
at  “Water  Surface  Profiles.” 

The  RMS  flood  assessment  process  (bottom  of  Figure  1)  was  not  as  well-defined  by  the 
user  during  the  task  analysis  process.  Consequently,  the  GIS  User  Information 
Requirements  previously  mentioned  were  chosen  as  a  guide  for  the  type  of  analysis 
and  information  that  should  be  included  within  the  interface.  The  post-disaster 
information  categories  include  land  areas  affected,  facility  damage,  public  and  private 
utility  damage,  transportation/infrastructure  damage,  hazardous/toxic  materials 
facility  damage,  flood  control  damage,  and  communication  system  damage.  The  basic 
output  needs  were  identified  as  maps  of  flood  depth  and  extent  that  could  be  spatially 
assessed  in  conjunction  with  geographic,  demographic,  and  economic  data. 
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It  is  possible  that  some  decisionmakers  would  like  to  explore  flood  information  in  a 
specific  sequence,  perhaps  one  that  reflects  a  particular  decisionmaking  process.  This 
was  not  defined  by  the  task  analysis  for  RMS.  Ideally,  a  decision-support  system 
would  not  only  provide  useful  information,  but  allow  alternative  decisions  to  be 
generated  and  compared  based  on  a  combination  of  different  values. 

In  addition  to  the  specific  tasks  required  by  RMS,  the  interface  must  support 
secondary  tasks,  such  as  file  editing,  status  reports,  and  the  extraction  of  system  help. 
Interface  “devices”  for  user  input  and  graphic  display  must  be  incorporated  to  support 
these  tasks. 


User  Perceptions  and  Terminology 

The  system  diagram  provided  by  the  Omaha  District  technical  staff  communicated  the 
user’s  perception  of  the  sequence  of  tasks.  The  system  was  depicted  as  a  collection  of 
modeling  and  data  objects.  This  chart  revealed  the  terminology  used  by  engineers 
familiar  with  hydrologic  and  hydraulic  modeling  software  and  other  modeling  and  GIS 
technology.  Because  it  is  possible  that  the  ultimate  user  (the  decisionmaker)  will  not 
be  familiar  with  all  the  specific  software  chosen  and  because  individual  software 
components  could  eventually  be  replaced  with  different  or  updated  technology ,  general 
terms  for  the  system  tasks  were  sought  to  replace  the  names  of  the  actual  software  or 
model  in  use.  Omaha  staff  responded  positively  to  the  concept  of  using  terms  that 
reflected  system  function  rather  than  specific  software  names  and  suggested  some 
substitute  terms  they  felt  to  be  even  more  appropriate. 


System  Requirements 

Omaha  District  chose  to  use  existing  computer  technology  rather  than  write  new  code 
for  each  specific  task.  A  benefit  of  this  is  the  ability  to  redirect  energy  and  resources 
from  the  development  of  the  computer  environment  to  the  development  of  the 
application  itself.  Another  benefit  is  that  the  capabilities,  limitations,  and  assump¬ 
tions  of  existing  technology  are  more  likely  to  already  be  documented.  Each  chosen 
component  is  public-domain,  which  translates  to  accessibility  (but  not  necessarily  to 
consistent  and  continous  software  support).  Where  a  common  database  does  not  exist 
between  the  components,  flat  text  files  are  used  as  intermediate  files  to  bridge  data 
flow  between  models.  Shell  scripts  are  used  as  command  bridges  between  the 
components. 
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Rainfall  Estimation 

Precipitation  tracking  and  forecasting  software  developed  at  USAWES  was  chosen  for 
incorporation  in  RMS  (Engdahl,  Bae,  and  Georgakakos  1991,  pp  405-409).  This 
software  uses  National  Weather  Service  (NWS)  ground  based  radar  data  as  it  is 
produced  and  converts  it  into  spatially  distributed  rainfall  totals.  This  prototype 
software  is  intended  to  produce  precipitation  data  for  input  to  existing  lumped 
parameter  hydrologic  models.  As  the  quality  of  radar  data  images  and  the  under¬ 
standing  of  the  spatial  structure  of  storms  improves,  it  is  possible  that  precipitation 
data  may  be  created  for  input  to  spatially  distributed  models.  The  prototype  software 
used  in  the  RMS  demonstration  is  being  replaced  by  a  new  phase  of  software  that  will 
directly  use  the  high  quality  NEXRAD  data  produced  by  the  NWS  and  output  data  to 
the  HEC-DSS  data  storage  system  (USACE  1990b).  Precipitation  values  may  be 
subsequently  extracted  from  DSS  for  input  into  HEC  modeling  software,  such  as  the 
HEC-1F  Flood  Hydrograph  software. 

Hydrologic  Modeling 

A  hydrologic  modeling  component  was  incorporated  into  RMS  to  provide  short-term 
forecasts  of  the  unregulated  inflow  of  tributaries  to  the  Missouri  River.  The  chosen 
HEC-1F  modeling  software,  developed  at  the  Hydrologic  Engineering  Center  (HEC), 
is  designed  for  use  in  real-time  flood  forecasting  and  flood  control  operations  (USACE 
1989,  p  iii).  It  is  a  special  version  of  the  HEC-1  Flood  Hydrograph  package,  a  lumped 
parameter  hydrologic  model  that  simulates  the  surface  runoff  response  of  a  river  basin 
to  precipitation  by  representing  the  basin  as  an  interconnected  system  of  hydrologic 
and  hydraulic  components  (USACE  1990a).  The  two  main  capabilities  of  HEC-1  used 
by  HEC-1F  are  parameter  estimation  and  precipitation-runoff  simulation  using  unit 
hydrograph  and  hydrologic  routing  procedures  (USACE  1989,  p  3).  Parameter 
estimation  is  used  to  estimate  runoff  parameters,  such  as  loss  rate,  unit  hydrograph, 
and  base  flow,  in  real  time.  Precipitation  forecasts  may  be  used  to  forecast  runoff. 
This  program  and  other  HEC  programs  were  chosen  by  Omaha  district  based  on  their 
“universal  acceptance  and  the  likelihood  that  they  will  be  sanctioned  by  other 
organizations”  (Fischenich  1991). 

Hydraulic  Modeling 


A  hydraulic  modeling  component  is  required  within  the  system  for  generating  water 
surface  elevations  at  channel  cross-sections.  The  HEC-2  Water  Surface  Profiles 
program  was  chosen  for  the  initial  RMS  prototype.  This  well-established  program 
calculates  water  surface  profiles  for  steady  gradually  varied  flow  in  natural  or  man¬ 
made  channels.  For  given  flow  values,  HEC-2  will  compute  the  water  surface 
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elevation  for  specified  cross-sections  of  interest.  The  effects  of  channel  obstructions, 
such  as  bridges,  culverts,  and  structures  in  the  floodplain  may  be  taken  into  account 
by  the  model.  An  advantage  to  using  this  modeling  component  is  that  a  GIS  program 
has  been  previously  developed  within  GRASS  that  will  translate  this  model’s  output 
into  flood  extent  maps  (USACE  1990b). 

Omaha  District  has  considered  the  future  integration  of  UNET  software  as  a 
substitute  for  the  HEC-2  software.  UNET  modeling  software  is  a  one-dimensional 
unsteady  flow  program  (USACE  1992).  It  incorporates  equations  that  can  account  for 
levee  failures  and  storage  interactions.  This  capability  would  be  of  advantage  to  RMS 
because  levee  failures  have  a  large  impact  on  river  hydraulics  and  thus  predicted  flood 
extent.  Another  advantage  to  using  UNET  is  that  it  takes  input  directly  from  and 
provides  output  directly  to  the  HEC-DSS  database,  which  would  simplify  the  link 
between  HEC-1F  and  the  hydraulic  component.  Currently  no  GRASS  program 
translates  UNET  output  into  flood  extent  and  depth  maps,  which  has  caused  the 
present  delay  in  linking  UNET  to  the  GUI. 

Data  Storage  System 

The  HEC-DSS  data  storage  system  is  used  to  store,  retrieve,  and  display  time-series 
data  for  both  the  rainfall  estimation  and  hydrologic  modeling  components  of  RMS. 
Ideally  a  common  database  format  would  exist  for  the  system  that  would  allow  each 
component  to  directly  input  and/or  extract  needed  information.  The  use  of  multiple 
software  components,  however,  often  requires  the  integration  of  different  databases. 
While  HEC-1F  and  the  precipitation  estimation  software  are  linked  by  HEC  Database 
Storage  System  (DSS)  database,  HEC-2  is  not.  Flat  text  files  were  used  to  bridge  data 
flow  between  HEC-1F  and  HEC-2.  A  GRASS  program  already  exists  to  extract  data 
from  a  HEC-2  ASCII  output  file  and  incorporate  them  into  the  GRASS  data  format. 

DSS  display  programs  exist  for  the  display  and  tabulation  of  modeling  results  for 
review  and  comparison  with  observed  data.  DSS  utility  programs  exist  for  the 
manipulation,  editing,  and  analysis  of  results  (USACE  1990b).  It  has  been  stated  that 
DSS  is  much  more  efficient  than  conventional  relational  data  bases  for  time  series 
data  (USACE  1992). 

Geographic  Information  System 

Spatial  analysis  functions  are  performed  by  GRASS  (Westervelt  et  al.  1989).  GRASS 
was  developed  by  the  U.S.  Army  Corps  of  Engineers  Construction  Engineering 
Research  Laboratories  (USACERL)  as  a  public-domain  raster-based  GIS.  Its  use  as 
a  tool  for  environmental  modeling  is  rapidly  increasing  and  many  public  and  private 
organizations  are  choosing  to  integrate  it  into  their  environmental  planning  and 
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research  programs  (Martin  et  al.  1989).  Both  the  GRASS  and  ARC/INFO  GIS  (1991) 
are  used  by  Omaha  District  for  their  RMS  prototype.  A  prime  reason  Omaha  District 
desired  the  development  of  a  GRASS-based  interface  to  the  RMS  prototype  is  the 
availability  of  GRASS  in  district  offices.  Although  the  RMS  prototype  was  developed 
specifically  for  the  Oahe  Dam  Safety  Project,  such  a  system  could  be  adapted  to  other 
reservoirs  managed  by  the  Corps  of  Engineers. 

Another  reason  for  using  GRASS  is  that  its  raster-based  data  structure  is  well-suited 
for  the  modeling  and  assessment  of  spatially  distributed  phenomena  and  impacts.  The 
GRASS  f-tools  software  generate  flood  depth  and  extent  maps,  which  can  be  overlaid 
with  other  data  layers  to  spatially  assess  impact.  The  fact  that  GRASS  is  public- 
domain  is  also  beneficial  to  the  RMS  system.  Because  its  code  is  open,  it  can  be 
competitively  adapted  to  suit  a  specific  application.  Updates  and  code  contributed  to 
GRASS  may  be  obtained  free  of  charge.  The  interface  can  be  adapted  as  the 
contributed  code  expands  the  hydrologic  modeling  capabilities  of  GRASS. 

GRASS  is  based  on  UNIX,  a  universal  operating  system,  increasing  the  likelihood  of 
its  compatibility  with  other  systems.  The  command  line  format  of  GRASS  is  conducive 
to  interface  design,  as  GRASS  commands  can  be  directly  encoded  within  a  custom 
interface,  and  GRASS  macros  can  be  created  and  used  in  real  time. 

Xgen  Interface  Generator  Program 

The  public-domain  Xgen  software  was  used  to  generate  the  interface  prototype.  It  is 
an  object-oriented  code  generator  that  implements  interfaces  through  X-windows  using 
the  Motif™  Toolkit  (1993).  Its  basis  on  the  widely  used,  public  domain  X-windows 
windowing  environment  provides  cross-platform  compatibility  for  the  final  interface 
and  allows  it  to  be  remotely  operated.  This  software  was  designed  for  the  rapid 
generation  of  graphical  user  interfaces  within  existing  shell  level  programs  (Buehler 
and  Poulsen  1989).  Several  of  the  capabilities  of  Xgen  that  make  it  useful  for  general 
interface  design  have  been  previously  identified  by  Poulsen  (1992,  p  26).  It  is  able  to 
store  parameters  input  by  the  interface  user  and  execute  shell  level  commands  that 
use  these  input  parameters.  The  output  of  individual  modeling  components  may  be 
captured  within  interface  variables  and  fed  to  subsequently  activated  system 
components.  Another  useful  feature  is  the  ability  to  specify  whether  an  interface 
command  must  be  completed  before  continued  system  execution  or  whether  system 
execution  may  proceed  while  the  current  task  is  completed.  This  is  an  especially 
important  capability  when  task  sequence  is  critical,  such  as  for  flood  prediction. 

Another  advantage  to  using  Xgen  is  that  the  Xgen  script  written  by  the  interface 
programmer  does  not  have  to  be  compiled,  and  thus  may  be  run  immediately  to  test 
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program  changes.  The  interface  developer  does  not  have  to  know  and  cannot  use  a 
high-level  programming  language  to  create  the  functioning  interface. 


Data 

RMS  operation  depends  on  the  pre-existence  of  certain  data.  A  large  portion  of  system 
implementation  is  the  creation  of  the  required  database.  By  having  the  database 
already  established,  much  time  is  saved  and  possible  errors  in  data  translation 
reduced.  The  user  should  have  to  provide  only  real-time  data  and  judgments.  Some 
real-time  data  may  be  collected  directly  by  the  computer  system,  such  as  radar  images 
for  rainfall  estimation.  Currently  spillway  discharge  and  downstream  boundary 
conditions  are  input  by  the  user.  These  could  ultimately  be  collected  by  automatic 
gages.  Reservoir  releases  are  input  as  desired  by  the  user  to  evaluate  various  release 
scenarios  in  relation  to  downstream  impacts. 

The  pre-existing  database  would  ideally  be  updated  on  a  regular  basis.  For  instance, 
landuse  maps  and  topography  maps  need  to  be  updated  periodically  to  reflect 
development.  HEC-1  and  HEC-2  input  files  may  also  need  to  be  updated  to  reflect 
land  use  changes  or  seasonally  changing  conditions.  Flood  events  themselves  cause 
changes  that  should  be  reflected  in  the  input  files.  Policies  for  the  update  of  such 
systems  should  be  established,  to  ensure  that  the  system  is  ready  for  emergency  use. 

Ideally,  GRASS  data  layers  that  correspond  closely  with  the  information  requirements 
established  by  EMIS-SDTG  may  be  included  in  the  database.  The  RMS  prototype 
interface  uses  the  GRASS  site  list  format  to  store  site  information,  such  as  phone 
number,  addresses,  and  contacts.  A  database  software  package  was  not  used  to  store 
additional  site  and  tabular  data.  Table  1  describes  the  necessary  data  for  the  RMS 
system  prototype  defined  in  this  document. 
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Software 

Data  Input 

Format 

Means  of  Input 

Source 

Rainfall 

Estimation 

HEC-1F 


HEC-2 


GRASS  f-tools 


Radar  VIP  array 

Emodel  input _ 

Precipitation  values _ 

_  Fmodel  input _ 

Cross  section 
geometry,  reach 
lengths,  direction  of 
flow,  loss  coefficients 

Flow  regime,  loss 
coefficients 

Tributary  inflow 


Spillway  discharge 
Reservoir  discharge 
Downstream  pool  stage 
Water  surface  elevation 
Channel  cross-sections 


Formatted  ASCII  file 

DSS  file _ 

Formated  ASCII  file 
Formatted  ASCII  file 


Automatic 

Automatic 

Automatic 

Automatic 

Automatic 


Real-time 

Pre-existin 

Real-time 

Pre-existing 

Pre-existing 


Digital  elevation  model, 
30  M  resolution 

Spatial  Analysis  Flood  depth  and  extent 
Graphical  Display  _ 

Area  info,  (i.e.,  land 
use,  and  population) 

Linear  info,  (i.e., 
political  boundaries, 
roads,  waterways,  etc.) 

Site  info,  (i.e., 

_  I  hospitals,  and  schools) 


Numeric  string 

Automatic 

Pre-existing,  edited 
by  expert  user 

Numeric  string 

Automatically 
extracted  from 
HEC-1F  output 

Real-time 

Numeric  string 

By  the  user 

Real-time 

Numeric  string 

By  the  user 

Real-time 

Numeric  string 

By  the  user 

Real-time 

HEC-2  ASCII  output 

Automatic 

Real-time 

GRASS  vector  file 

Automatic 

Pre-existing 

GRASS  raster  file 

Automatic 

Pre-existing 

GRASS  raster  file 

Generated  using 
f-tools 

Real-time 

GRASS  raster  file 

Selected  by  the 
user 

Pre-existing 

GRASS  vector  file 

Selected  by  the 
user 

Pre-existing 

GRASS  site  file 

Selected  by  the 
user 

Pre-existing 
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5  GUI  Description  and  Evaluation 


The  visual  and  operational  design  of  the  prototype  GUI  may  be  evaluated  in  terms  of 
the  interface  standards  described  in  Chapter  3,  as  well  as  by  its  ability  to  support  the 
project  goals  of  providing  procedural  support  and  improved  information  transfer. 


Organization 

The  interface  layout  was  organized  to  include  specific  areas  for  primary  task  control, 
subsidiary  task  control,  input,  and  graphic  display  (Figure  2).  The  specification  of 
these  areas  is  intended  to  provide  consistency  in  user-interface  interaction.  They 
remain  in  place  during  the  entire  interface  operation.  Separate  flood  assessment  and 
display  control  boards  pop  up  in  the  primary  task  area  when  activated  from  the 
“permanent”  RMS  operation  chart.  By  physically  grouping  associated  interface 
functions  that  require  similar  action  from  the  user  and  that  provide  similar  response, 
the  user  can  learn  to  expect  certain  reactions  from  the  different  areas  of  the  interface 
and  thus  their  mental  model  of  the  system  and  its  functions  will  be  strengthened.  The 
primary  task  control  area  of  the  interface  provides  control  of  the  three  main  tasks 
identified  through  task  analysis:  flood  prediction,  flood  assessment,  and  display.  The 
subsidiary  task  control  area  includes  user  support  functions  such  as  help  and  system 
status  reporting,  file  editing,  and  system  exiting.  An  attempt  was  made  to  avoid 
excess  functionality,  while  at  the  same  time  providing  additional  functions  for  the 
more  advanced  user  who  may  want  to  directly  edit  input  files.  The  main  tasks  and  the 
supporting  tasks  were  kept  separate  to  prevent  confusion  about  the  required  main  task 

sequence. 

All  help  messages,  prompts,  user  input,  and  file  editing  occurs  in  the  input  area.  Items 
chosen  through  the  graphic  display  task  board  are  displayed  m  the  display  area. 
While  display  content  is  controlled  in  the  primary  task  control  area,  manipulation  of 
the  display  window  itself,  such  as  window  zooming  and  erasing,  is  controlled  within 

the  display  area. 
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Primary  Tasks 


Figure  2.  Interface  layout. 


System  Presentation 

Because  there  will  be  frequent  and  long  gaps  in  system  use,  explicit  guidance  should 
be  provided  to  the  RMS  user.  A  design  goal  was  to  simplify  the  sequence  of  tasks  as 
much  as  possible  and  present  them  in  terms  meaningful  to  the  user.  As  mentioned  in 
Chapter  4,  two  trial  designs  for  the  primary  task  board  were  developed.  One 
presented  the  flood  prediction  and  assessment  sequence  as  consecutive  menus  that 
allowed  visual  and  physical  access  to  functional  buttons  only  as  they  were  needed. 
Figures  3  and  4  show  the  first  two  interface  menus  of  the  design.  This  design  was 
intended  to  focus  the  user  on  the  task  at  hand,  but  still  the  the  entire  sequence  was  not 
visible;  the  user  could  not  anticipate  the  next  task  and  there  were  no  visible  reminders 
of  completed  tasks.  The  second  design  incorporated  task  buttons  in  a  flow  chart  form, 
similar  to  the  user’s  initial  description  of  the  system  (Figure  5).  Users  preferred  this 
explicit  representation  of  the  system  framework  and  it  was  retained. 

Powel  (1991)  recommends  certain  qualities  of  a  GUI.  The  user  should  be  visually 
directed  to  important  information,  screen  text  should  be  distinguishable  from  user  text 
entries,  and  the  user  should  be  kept  focused  on  the  current  task  by  the  minimization 


30 


USACERL  TR  EC-95/03 


Figure  3.  First  interface  menu. 

of  screen  clutter.  There  is  consistency  of  position,  color,  type,  spacing,  order,  and 
capitalization,  clarity  and  conciseness  of  terminology,  and  use  of  color  to  reinforce 
meaning.  It  is  also  desirable  to  reduce  keystrokes,  anticipate  the  user’s  next  move, 
provide  error  messages  that  help  solve  problems,  make  short-cuts  available,  and  use 
appropriate  text  and  tone  for  error  and  warning  messages. 
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Figure  4.  Second  interface  menu. 
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Select  Project  Location 


:  Select:  .; 
Previous: 
;  l-TriaiV: 


Generate  Water 
Surtace  Proilie 


Specific 

tinpacty 


Figure  5.  Task  buttons  incorporated  into  flowchart  format. 


The  button  labels  incorporated  into  the  GUI  are  specific  action  statements  that 
describe  the  task  activated  by  the  button,  such  as  “Generate  Tributary  Inflows  or 
“Predict  Flood  Extent”  (Figure  6).  This  reinforces  the  user’s  conceptual  understanding 
of  the  system  and  individual  task  requirements.  These  action  statements  do  not  reveal 
the  specific  software  activated  by  the  system,  as  the  chosen  software  could  conceptu¬ 
ally  be  interchanged  with  other  software  products  of  similar  capabilities.  The  button 
that  activates  the  HEC-1F  model  is  labeled  “Model  Tributary  Inflows,”  rather  than 
“Run  HEC-1F.”  Labeling  conventions  were  established  for  buttons  of  particular 
function  classes,  such  as  “OK”  for  input  verification  or  “Return”  for  backtracking 
through  the  system.  Each  button  in  the  operation  chart  is  initially  “grayed  out”  and 
may  not  be  activated  until  the  sufficient  preceeding  steps  have  been  completed. 
Buttons  become  “active”  or  available  for  use  when  all  of  the  preceding  steps  have  been 
completed.  Buttons  darken  when  active  to  direct  the  user’s  actions  and  to  show  the 

user’s  place  in  the  task  sequence. 
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Interface  colors  were  chosen  to  enhance 
procedural  support,  but  were  used  con¬ 
servatively  to  avoid  creating  a  cluttered, 
distracting  screen.  It  was  decided  that 
the  color  of  the  primary  task  or  “action” 
buttons  should  contrast  the  most  with 
the  background  interface  color  to  attract 
the  attention  of  the  user  to  the  primary 
tasks.  Gray  was  chosen  as  the  back¬ 
ground  interface  color  and  light  turquoise 
for  the  system  task  button.  Turquoise 
was  chosen  because  of  the  general  con¬ 
vention  that  “green”  colors  symbolize 
action.  Black  letters  stand  out  against 
the  turquoise  buttons.  Permanent  screen 
titles  and  secondary  function  buttons, 
such  as  “Status”  and  “Help,”  consist  of 
black  letters  against  the  gray  back¬ 
ground,  which  does  not  immediately 
attract  attention.  Prompts  for  user  input 
or  file  selection  all  appear  in  white  letters 
against  a  blue  background.  This  change 
in  color  format  alerts  the  user  that  data 
input  is  required.  The  consistent  use  of 
color  reinforces  the  user’s  expectations  of 
the  different  interface  components. 

GUI  Operation 

As  noted  in  the  system  requirements 
section,  Xgen  runs  on  the  UNIX  operat¬ 
ing  system  and  requires  the  standard  X- 
window  environment.  The  interface  is 
activated  by  simply  typing  “xgen 
<script.name>”  after  the  UNIX  prompt. 
This  is  the  only  direct  interaction  with 
UNIX  required.  All  programs  subse¬ 
quently  used  are  activated  through  inter¬ 
face  buttons. 


RMS  Operation 


Figure  6.  RMS  operations  chart. 
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Procedural  Support 

The  GUI  is  intended  to  aid  the  emergency  decisionmaking  process  by  providing  the 
decisionmaker  with  the  ability  to  quickly  process  information  into  an  organized  and 
accessible  format.  This  goal  is  achieved  by  the  development  of  an  operation  flowchart 
format  for  the  interface  structure.  As  noted  earlier,  the  GUI  operation  flowchart 
(Figure  6)  closely  parallels  the  functional  diagram  of  RMS  (Figure  2).  Each  step  within 
the  chart  is  a  user  selectable  button,  which  when  activated  prompts  for  needed 
parameters,  inputs  these  into  the  appropriate  model,  executes  the  model,  and  then 
captures  the  output  for  subsequent  input  into  the  next  component  within  the  task 
sequence.  By  preprogramming  buttons  to  activate  support  programs,  the  need  for  the 
user  to  memorize  command  syntax  is  reduced.  This  operations  chart  format  was  well- 
received  by  the  user. 

The  first  step  within  the  operations  chart  “Select  Location”  prompts  the  user  to  select 
the  mapset  corresponding  to  the  region  of  interest  (Figure  7).  The  user  must  next 
indicate  a  wish  to  run  a  new  simulation  or  assess  previously  modeled  flood  conditions 
by  clicking  either  “Enter  New  Conditions”  or  “Select  Default  Flood”  from  the 
operations  chart,  respectively.  If  assessment  of  default  flood  conditions  is  chosen  by 
the  user,  he/she  is  prompted  to  select  a  flood  event  and  then  allowed  to  proceed  directly 
to  impact  assessment  and  map  display  by  activating  “Assess  Economic  Impacts, 
“Assess  Specific  Impacts,”  or  “Display  Maps.”  If  a  new  simulation  is  requested,  the 
user  is  prompted  to  type  in  a  name  for  the  new  trial  (Figure  8).  On  entering  this  name, 
the  new  trial  sequence  begins. 

The  first  four  buttons  in  the  trial  sequence  (Figure  6)  create  input  for  water  surface 
profile  generation.  Activating  the  “Tributary  Inflows  button  prompts  the  user  to 
select  input  files  for  runoff  prediction  (Figure  9).  The  expert  user  may  edit  input  files 
prior  to  model  run.  Model  calibration  is  not  specifically  supported  by  the  interface. 
The  user  may  input  the  rainfall  data  (Figure  10),  although  this  step  is  not  required 
since  the  interface  is  designed  to  automatically  extract  precipitation  values  from  DSS 
files.  During  interface  testing,  precipitation  values  were  extracted  from  sample  DSS 


Return  With  No  Selection 

PERMANENT 

flood 

omaha 


Figure  7.  Prompt  to  select  mapset.  Figure  8.  Prompt  for  trial  name. 


Enter  Name  of  Trial: 

trial.4.3.93 

Ok 

Cancel 
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files  previously  generated  by  Omaha 
District  with  the  WES  rainfall  prediction 
software  using  fabricated  radar  images. 
Modeling  tributary  inflow  is  activated  on 
file  selection. 

“Spillway  Flow”  (Figure  11)  prompts  for 
spillway  discharge  entry,  obtained  by 
telephone  from  reservoir  personnel,  or  by 
automatic  gages.  Pressing  “D/S  Bound¬ 
ary  Conditions”  prompts  for  input-gaged 
pool  elevation  at  Big  Bend  Dam  (Figure 
12).  The  input  of  reservoir  release  is  the 
last  task  of  the  four-button  sequence  to 
be  completed  before  calculating  water 
surface  profiles.  A  click  on  “Reservoir 
Release”  brings  a  prompt  to  enter  a  reser¬ 
voir  release  rate  (Figure  13).  Previously 
generated  tributary  inflow,  spillway  flow, 
downstream  pool  stage,  and  the  specified 
reservoir  release  rate  are  input  to  the 
hydraulic  model  input  file  on  activating 
“Generate  Water  Surface  Profiles,”  and 
the  hydraulic  modeling  program  is  run. 
When  the  water  surface  profile  genera¬ 
tion  is  complete,  model  output  is  cap¬ 
tured  in  an  on-screen  editor  to  allow  the 
user  to  verify  that  water  surface  profile 
was  generated  successfully  before  invok¬ 
ing  map  creation,  itself  a  lengthy  interpo¬ 
lation  process  (Figure  14).  Interpolated 
flood  surface  and  flood  depth  maps  are 
generated  by  clicking  “Predict  Flood  Ex¬ 
tent.”  The  separate  buttons  for  these  two 
functions  gives  intermediate  system  feed¬ 
back,  which  outweighs  the  cost  of  the 
extra  step. 

The  operations  chart  guides  the  user 
quickly  through  the  prediction  and  as¬ 
sessment  process  by  limiting  the  actions 


Figure  10.  Prompt  to  select  rainfall  data. 
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to  be  performed  at  each  step.  In 
an  emergency  management  sys¬ 
tem,  the  user  must  not  perform 
functions  out  of  the  required 
sequence  or  be  trapped  while 
exploring  system  functions.  How¬ 
ever,  the  chart  layout  does  allow 
the  system  to  rim  repetitively 
once  values  have  been  entered  for 
all  required  parameters.  In  addi¬ 
tion  to  allowing  repetitive  runs  to 
test  different  reservoir  release 
scenarios,  it  allows  the  user  to 
“back  up”  and  change  input,  thus 
prevents  a  need  to  restart  the 
process  in  case  of  an  error  or 
change  in  input. 

An  associated  feature  is  the  sta¬ 
tus  button  (Figure  15),  which 
provides  the  user  with  a  record  of 
the  previous  input.  If  the  user  is 
called  away  from  the  terminal, 
upon  return  the  status  button 
may  be  used  to  check  the  param¬ 
eters  which  had  been  previously 
entered  or  to  confirm  the  step 
last  completed.  For  example,  if 
the  user  was  called  away  from 
the  terminal  prior  to  water  sur¬ 
face  profile  generation,  on  return 
the  user  could  check  the  values 
entered  for  upstream  and  down¬ 
stream  boundary  conditions  to 
confirm  whether  or  not  they  were 
consistent  with  any  new  informa¬ 
tion  that  had  come  in.  The  sta¬ 
tus  button  may  also  be  used  to 
determine  parameters  that  were 
input  during  previous  system 
runs.  This  removes  the  menial 
task  of  remembering  previous 


Enter  Spillway  Discharge: 
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cfs 
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Continue 


Cancel 


Figure  1 1 .  Prompt  to  input  spillway  discharge. 


Enter  Operating  Pool  Level: 
1415 


Select  Units: 


feet 


meters 


Continue 


Cancel 


Figure  12.  Prompt  to  downstream  pool  stage. 


Enter  Reservoir  Release  Rate: 
100000 _ 


Select  Units: 


cfs 

cms 

Continue 

Cancel 

Figure  13.  Prompt  to  reservoir  release. 
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Command  Output  Editor 

JFIIe  Edit  Help 

mpy2/omaha/toDC/HEC2/hec2data ;  editaB;hec2;  xterm  -geometry  82x12+305+300  -e-sh  -c  ‘runmessg’;  dorun  hec2.data  hec2.o 

Jt; 

THIS  RUN  EXECUTEO  Thu  Oec  2  18:13:56 1993  Thu  Dec  2  18:19:56  1993 

HEC-2  WATER  SURFACE  PROFILES 

Version  4.6.3:  July  1991 
•  •••••••»*•**  *******  ***************  ********* 

1 1  MISSOURI  RIVER  MAINSTEM  RESERVOIR  EMERGENCY  SYSTEM  OPERATING  PLAN  (ESOP) 

12  OAHE  DAM  TO  BIG  BEND  DAM  -  RIVER  Ml.  987.4  TO  1072.0 

1 2  ROHDE  /  CEMRO  -ED  -  HD  /  SEPTEMBER  1 990  UPDATED  MAY  1 992 

13  OAHE  RELEASE  - 100,000  CFS;  BIG  BEND  POOL  NEEDED  TO  PASS  Q  =  1405.0 

ESOP  STUDY 

FOR  STEADY  STATE  100000  START  POOL  AT  MIN  OPERATING  POOL  OF  1415 

RUN  OTHER  POOLS  OF  1415,  1424.8,  1433.6 

J1  ICHECK  INQ  NINV  IDIR  STRT  METRIC  HVINS  Q  WSEL  FQ 

-10  2  0  0  0  0  0  0  1415 

J2  NPROF  IPLOT  PREVS  XSECV  XSECH  FN  ALLDC  IBW  CHNIM  ITRACE 

1  0  -1  0  000000 

J3  VARIABLE  CODES  FOR  SUMMARY  PRINTOUT 

98  43  1  42  8  25  39  5  36  63 

Figure  14.  Water  surface  profile  generation  output  file. 


Project  Location: 

Trial  Name: 

Starting  Time: 

HEC1F  E-Model  Input: 
HECIFF-Model  Input: 
DSS  File: 

Spillway  Flow: 
Downstream  Boundary: 
Reservoir  Release: 

Flood  Depth  Map: 

Flood  Surface  Map: 


Continue 


input  from  the  user  and  reas¬ 
signs  it  to  the  computer. 

Subsidiary  task  buttons  are 
included  for  activities  outside  the 
normal  flood  prediction  and  as¬ 
sessment  sequence  (Figure  16). 
Information  about  the  system 
and  its  operation  is  constantly 
available  to  the  user  through 
this  selection.  Several  levels  of 
help  are  provided.  A  general 
help  button  is  provided,  which 
explains  the  basic  functions  of 
the  interface.  Context-depen¬ 
dent  help  on  each  specific  proce¬ 
dure  is  directly  linked  to  the 
buttons  that  activate  those  pro¬ 
cedures. 


Figure  15.  Status  report. 
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Information  Transfer 

The  GUI  improves  information  transfer  between  the  user  and  computer  by  improving 
the  efficiency  of  inputs  and  outputs.  The  GUI  reduces  the  input  requirements  of  the 
user.  Each  procedure  in  the  system  requires  input  from  another  procedures  data  file, 
or  the  user.  If  the  source  of  input  is  another  procedure,  then  the  data  is  accessed 
without  intervention  by  the  user.  Computer  algorithms  may  be  used  to  process 
information  into  the  next  required  format.  If  the  source  of  input  is  a  data  file,  then  the 
user  is  prompted  to  select  a  file  from  a  display  of  appropriate  files,  which  also  reduces 
required  user  input.  Where  input  parameters  must  be  entered  directly  by  the  user, 
spaces  for  text  entry  are  provided  with  instructions  as  to  which  parameter  must  be 
typed  in.  A  potential  enhancement  would  be  to  provide  computer  checks  to  ensure  the 
parameters  input  by  the  user  fall  within  the  acceptable  range. 
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|  7.  Transportation  Systems 
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Some  portions  of  a  model  input  file, 
e.g.,  physical  descriptions  of  a 
channel  network,  will  not  change 
between  model  runs.  Other  parts, 
e.g.,  precipitation  or  base  flow  val¬ 
ues,  may  need  updating.  Rather 
than  creating  a  new  input  file  for 
each  model  run,  an  existing  input 
file  may  be  modified,  either  auto¬ 
matically  or  by  the  user,  to  reflect 
the  new  conditions.  The  output 
from  a  standard  model  run  may  be 
extensive  and  include  much  nones¬ 
sential  information  to  the  emer¬ 
gency  decisionmaker.  An  interface 
may  be  designed  to  extract  immedi¬ 
ately  useful  information. 

The  GUI  directly  supports  impact 
assessment,  including  the  query 
and  analysis  of  geophysical  and 
human  resource  data.  The  assess¬ 
ment  portion  of  the  interface  cur¬ 
rently  provides  samples  of  the  in¬ 
formation  that  can  be  made  avail¬ 
able  for  decisionmaking  (Figure 
17).  As  previously  stated,  it  is 
based  on  the  GIS  User  Information 
Requirements  compiled  by 
HQUSACE.  It  was  desired  that 
the  system  display  data  in  the  form 
required  to  perform  the  main  sys¬ 
tem  task,  flood  assessment.  The 
user  should  not  have  to  translate 
displayed  data  into  this  form. 
Flood  depth  maps  representing 
historic  flood  occurrences  might  be 
provided  to  assess  the  relative 
magnitude  of  a  potential  flood  with 
a  past  flood  and  its  known  impacts. 


Figure  17.  Assessment  task  board. 
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This  portion  of  the  interface  can  be  expanded  as  information  requirements  are  better 
established  and  as  databases  are  created  to  provide  the  needed  information.  Since 
information  needs  may  vary  from  location  to  location,  some  degree  of  system  and 
interface  customization  would  be  required  for  implementation  at  other  locations. 

Area  statistics,  site  retrieval,  and  graphical  display  are  currently  incorporated  into 
this  portion  of  the  interface  to  demonstrate  potential  forms  of  the  production  of 
information  useful  for  impact  assessment.  These  functions  are  described  in  the 
proceeding  paragraphs. 

Area  Statistics.  The  generated  flood  depth  map  is  used  as  a  tool  for  the  spatial 
analysis  of  flood  impact.  It  is  specified  as  a  “mask”  prior  to  calculating  area  statistics 
for  other  raster  maps.  A  mask  causes  only  that  portion  of  a  map  that  falls  within  its 
boundaries  to  be  displayed  and/or  used  for  analysis.  A  report  of  flooded  land  use  areas 
is  generated  by  specifying  the  flood  depth  map  as  a  mask,  and  then  running  r.report, 
a  GRASS  raster  report  program  that  calculates  area  totals  for  all  categories  of  the 
displayed  or  masked  portion  of  the  land  use  raster  map.  A  coincidence  program  within 
GRASS,  r.coin,  calculates  the  area  coincidence  of  two  maps,  but  reports  category 
numbers ,  rather  than  labels,  and  so  is  not  as  immediately  useful  for  impact  reports. 
GIS  capabilities  were  also  used  to  calculate  affected  population.  Using  r.stats  with  a 
population  density  raster,  it  was  possible  to  output  a  report  of  the  total  square  meters 
of  each  population  density  raster.  Using  simple  UNIX  shell  scripts,  it  is  possible  to 
multiply  densities  by  these  areas,  and  then  sum  these  to  provide  a  custom  report  of 
population  affected. 

Site  Retrieval.  Flood  depth  maps  may  also  be  used  to  mask  or  filter  site  lists  to 
determine  the  particular  site  types,  such  as  hospitals  or  schools  that  fall  within  the 
flooded  area.  Buttons  are  included  within  the  GUI  that  immediately  extract  lists  of 
the  facilities  of  a  particular  type  whose  geographic  coordinates  fall  within  the 
predicted  flooded  area.  The  display  of  tabular  information  aids  in  the  quick  retrieval 
of  information  needed  for  use  in  emergency  assessment  and  response,  such  as  the 
location  of  all  hazardous  material  storage  sites  within  the  flooded  area  and  the  persons 
to  contact  with  warnings  (Figure  18).  While  GRASS  site  lists  are  fine  for  storing  and 
retrieving  small  amounts  of  information,  linkage  to  a  separate  database  system  is 
desirable  for  storing  and  extracting  the  larger  datasets  required  for  more  extensive 
flood  assessment  and  emergency  response  decisions. 
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Hazardous  Material  Sites  within  Flooded  Area 

Site:  Nam*:  Address:  Phone: 


hazmat 

Capitol  Food  Mart 

202  E.  Capitol,  Pierre  57501 

NA  \ 

hazmatIO 

Case  Power  &  Equip  J 

E.  Truck  Bypass, Pierre  57501 

NA 

hazmat12 

CJ's  66 

621  W.  Sioux,  Pierre  57501 

NA 

hazmat13 

Pierre  Farmers  Elevation  Assn 

2810  E.  Sioux 

NA 

hazmat8 

7-11  Store 

1225  Wells  Ave. 

NA 

hazmat14 

Ostlund  Chemical  Co. 

2009  East  Sioux, Pierre  57501 

NA 

Figure  18.  Tabular  display  of  emergency  assessment  and  reponse  information. 

Graphical  Display.  The  RMS  interface  enhances  the  user’s  ability  to  understand  the 
flood  conditions  by  allowing  the  graphical  display  of  system  output  (Figure  19). 
Common  hydraulic  and  hydrologic  models  present  forecasts  as  water  surface 
elevations  along  channel  cross  sections  or  hydrographs  at  point  locations.  For  this 
information  to  be  meaningful,  the  decisionmaker  would  need  to  have  a  detailed 
understanding  of  the  topography  of  the  area  being  modeled.  Flood  forecasts  are  more 
useful  to  the  decisionmaker  when  presented  in  terms  of  depth  and  extent.  The  display 
section  allows  flood  extent  maps  to  be  overlaid  with  other  raster,  vector,  or  site  maps 
(Figure  20)  to  visually  determine  which  features  lie  within  the  predicted  flooded  area. 
The  capability  to  simultaneously  display  maps  can  also  allow  the  user  to  compare 
historic  flood  maps  with  those  generated  by  the  system.  The  linked  GIS  capabilities 
allow  the  user  to  zoom  in  on  areas  of  interest  and  to  obtain  needed  geographic 
coordinates  and  map  categories,  such  as  flood  depth,  by  simply  clicking  the  location 
with  the  mouse  (Figure  21). 
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GRASS  4.1  -  Monitor:  *5 


Select  Region 


Figure  19.  Screen  display  showing  percent  of  flooded  land  by  use. 
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Figure  20.  Overlaid  flood  extend  maps  identify  features  within  flooded  areas. 


Figure  21 .  Display  task  board. 
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6  Summary  and  Recommendations 


Computer-based  systems  for  real-time  flood  forecasting  may  include  a  number  of 
capabilities,  including  data  acquisition  and  processing,  precipitation  analysis,  stream- 
flow  forecasting,  reservoir  system  analysis,  and  graphical  display  of  data  and 
simulation  results.  Incorporating  the  spatial  analysis  capabilities  of  a  GIS  into  flood 
response  systems  can  increase  the  effectiveness  of  such  systems  by  increasing  the 
speed  and  scale  of  data  manipulation,  and  enhancing  the  interpretation  of  typical 
hydrologic  and  hydraulic  model  output.  A  GIS  may  also  be  used  to  automate  the 
interpolation  of  channel  water  surface  elevations  into  water  surface  elevation  maps, 
to  overlay  water  surface  maps  onto  topographic  maps  to  determine  flood  depth,  and 
to  identify  sites  lying  within  the  flooded  area.  While  the  use  of  GIS  in  conjunction  with 
hydrologic  and  hydraulic  models  is  not  a  new  concept,  it  has  become  more  widespread 
and  sophisticated  in  relation  to  water  resources  applications.  The  potential  for  using 
GUI  in  real-time  flood  control  systems  has  been  recognized  by  various  government 
agencies  and  offices. 

A  GUI  that  links  system  components  in  a  unified  user  envoronment  may  best  address 
the  demands  of  a  complex,  multiple -component  system  and  the  needs  of  users  with  a 
range  of  computing  and  technical  skills.  The  GUI  may  reduce  the  number  of  steps  a 
user  must  complete  by  dividing  the  labor  appropriately  between  the  user  and  the 
computer.  Menial  tasks  may  be  automated,  and  the  steps  the  user  needs  to  take  more 
clearly  communicated  through  an  operations  chart.  In  addition  to  this  procedural 
support,  the  GUI  can  give  the  user  decision  support  by  providing  rapid  access  to 
information  critical  to  emergency  response. 

This  study  explored  the  technical  feasibility  of  creating  a  link  of  individual  software 
components  into  an  integrated  system  for  flood  prediction  and  assessment  that 
eliminates  the  need  for  the  decisionmaker  to  construct  the  simulation  process,  thereby 
freeing  time  for  evaluating  generated  information  and  making  decisions.  A  prototype 
GUI  was  created,  incorporating  several  ideal  characteristics  of  emergency  manage¬ 
ment  systems,  and  including  the  abilities  to  quickly  process,  organize,  and  retrieve 
large  quantities  of  information  into  an  easily  accessible  format.  The  system  was  also 
designed  to  produce  a  flood  map  of  a  current  disaster  and  to  model  a  series  of 
alternative  reservoir  release  scenarios  to  be  tested. 
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The  prototype  GUI  developed  in  this  study  provides  procedural  support  and  opera¬ 
tional  flow  charts  to  help  the  user  understand  system  tasks  through  the  use  of 
interactive,  process-oriented  interfaces  and  conventional  GUI  tools.  The  GUI  also 
reduces  the  number  of  steps  the  user  must  take  by  automating  menial  tasks. 

The  prototype  interface  was  evaluated  by  Omaha  District  decisionmakers,  who 
contributed  some  recommendations  for  further  development.  It  is  recommended  that 
a  well-defined  sequence  of  assessment  be  developed  based  on  further  analysis  of  the 
flood  emergency  decisionmaking  process.  A  true  decision-support  system  should  both 
generate  information  and  allow  a  comparison  of  alternative  decisions.  To  this  end,  it 
is  recommended  that  economic  analysis  software  (incorporating  cost/benefit,  tradeoff 
analyses,  etc.)  be  integrated  with  GIS  capabilities. 

It  is  also  recommended  that  the  prototype  GUI  be  expanded  to  include  additional  user 
prompts  and  an  expanded  online  help  to  give  users  detailed  descriptions  of  required 
parameters,  and  to  link  the  GUI  to  a  common  database  system  to  provide  access  to  a 
larger  range  of  useful  decisionmaking  data. 

It  is  further  recommended  that  an  auto  printout  capability  of  information  suitable  for 
radio  and  television  announcers  be  developed. 
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